IBIS Macromodel Task Group Meeting date: 14 Feb 2011 Members (asterisk for those attending): Agilent: Fangyi Rao * Radek Biernacki Altera: * David Banas Ansys: Samuel Mertens * Dan Dvorscak Curtis Clark Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: * Greg Edlund Intel: Michael Mirmak LSI Logic: Wenyi Jin Maxim Integrated Products: Mahbubul Bari Mentor Graphics: * John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: Randy Wolff NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: * Eckhard Lenski QLogic Corp. * James Zhou Sigrity: Brad Brim Kumar Keshavan Ken Willis SiSoft: * Walter Katz Todd Westerhoff Doug Burns * Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla The meeting was lead by Arpad Muranyi ------------------------------------------------------------------------ Opens: - Arpad: I can not meet next week - Walter moved to cancel the next meeting - Bob seconded -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad propose method to generalize BIRD 118 - In progress - Cadence update BIRD 144 - Done - Mike post Walter's updated presentation to ATM website - Not done ------------- New Discussion: Naming Rules BIRD (new): - Walter: Some characters that are allowed in parameter names are inconvenient for some parsers - The tap parameter violates our rules because names begin with numbers and '-' - We should be able to observe the new rule for future Reserved Parameters - For example, Dual-Dirac becomes Dual_Dirac - Should this go into 5.1 or 5.2? - Arpad: This is inconvenient for script languages but not urgent - Walter: Adge Hawes wants this change - Arpad: How are script languages affected by dashes? - It is just a string to be parsed - Walter: The parameter names can not easily become identical names in the other languages - Variable in many languages can't start with a number or have special characters - Ambrish: Should we just voluntarily avoid those names? - Walter: We can't voluntarily avoid the rules for Type Tap, because they are in the spec - Tools might use aliases to support those requirements - Bob: I'm neutral on this - Ambrish: Are number names really required for taps? - Walter read aloud the description of Type Tap - Radek: That is just an example, not a requirement - Arpad: If this is correct then we may have a tap ordering problem - We should look at this more carefully - Ambrish: It is an error to use tap values other than numbers - Radek: Agree with Arpad, we should look at this - James: What does "alias" mean here? - Walter: FOr example Dual_Dirac would be an alias for Dual-Dirac - James: Why not remove Dual-Dirac? - Walter: I would not object, but we would lose compatibility - Our general philosophy is to maintain backward compatibility - Arpad: There is a deadline to be considered for 5.1 - James: The spec says the model developer decides whether to follow convention - Walter: A, B, C could be used - That might be valid for floating taps - Ambrish: The model will understand it regardless - Arpad: How does the EDA tool understand them? - Ambrish: It doesn't have to - James: These are Model_Specific parameters - We should pick one name, but not both - Walter: If numbers are used the tool can see which are pre and post cursor taps - The tool can look at In parameters and use them - Radek: The names could be more informative, like Pre, Main, etc. - Arpad: We will have issues if tools can use In params themselves - Walter: The tool might manipulate the values specially, for backchannel for example - Ambrish: The model might expect a set of tap numbers without parameter names - James: It will be a user issue if the tool is changing taps - It has to work the same way across tools - Radek: ??? - Arpad: The names have to be meaningful if the tool is to use them - We would need a tap naming convention BIRD 118: - Arpad: BIRD 118 has names changed to a more generic format - The same changes will be needed in BIRD 117 BIRD 144: - Feras: We removed references to user defined corners - We added a port termination subparameter - It can be use with [External Model] - Need to tell EDA tool how to terminate floating power - Termination is given as resistance and voltage - Walter: Unterminated implies it is not hooked up - It would be simpler with an ISS subckt - Sometimes a 50 ohm ground is needed, sometimes it must be absent - We should find out about the derivation methods for S4Ps - Arpad: This relates to the isolation amplifier topic - We need to address ports that are not connected - Feras: With [External Model] we have to give information on unconnected ports - Walter: The port set is defined there - How can there be "additional" ports? - Feras: A model might have only in and out ports - How will the tool hook up power? - Radek: With ISS those connections are available - The circuit seems to assume ground - It provide a means to specify that may not be needed - Feras: Different buffer types may have different numbers of terminals - There are assumptions in the tools about 7 terminals, for example - Walter: [External Model] does not make that assumption - Arpad: Node declarations can help but they are not required - Feras: I can update to add that if we agree - Arpad showed the [External Circuit] diagram in IBIS 5.0 - James: It would help to map the proposal to the diagram - Arpad: The node names do not mean much here - Can't recall if [External Model] covers handling of extra nodes - Walter: What problem are we solving? - Feras: An [External Model] can have a transistor buffer model - [External Circuit] can have complex parasitics - James: Why fit into 7 ports if Touchstone can have many more? - Feras: It would be best to directly call Touchstone - James: That is just another way wrapping, which we can already do - Feras: It will be easier for my version of SPICE to deal with it - James: An example would help - Walter: These are shortcuts, but not clearly defined - Feras: It is easier to use with classic IBIS models - Arpad showed a wrapper example called "A" - Feras: We should not have to write wrappers for this every time - Arpad: BIRD 144 adds direct Touchstone instantiation, mine doesn't - Feras: Walter said 145 allows cascading, 144 doesn't - Arpad: For boundary conditions the Touchstone model better have zero drive impedance - Feras: There is a problem with floating nodes - Walter: We have floating nodes all the time - We just connect with a resistor to ground Meeting ended. ------------- Next meeting: 28 Feb 2011 12:00pm PT Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives